home *** CD-ROM | disk | FTP | other *** search
/ Super Audio / Super Audio.iso / replay / _armovie / documents / ae7doc next >
Encoding:
Text File  |  1997-11-10  |  8.9 KB  |  239 lines
  1. File format AE7: ARMovie
  2. ========================
  3.  
  4. Start of file:
  5.  
  6. String          ARMovie
  7. String          Movie name
  8. String          date and copyright details
  9. String          author and other details
  10. String          video compression format identifier     [0 -> no video]
  11. Decimal number  x size in pixels
  12. Decimal number  y size in pixels
  13. Decimal number  z pixel depth in bits [16 or 8]
  14. Decimal number  number of frames per second to project at
  15. String          sound compression format identifier     [0 -> no sound]
  16. Decimal number  sound replay rate in Hz (or fractions of)
  17. Decimal number  number of sound channels recorded ("reversed" if l<->r)
  18. Decimal number  sound precision ("linear" if linear, "unsigned" if unsigned)
  19. Decimal number  number of frames in a chunk
  20. Decimal number  number of chunks NC (chunks start at 0!!!!)
  21. Decimal number  "even" chunk size in bytes
  22. Decimal number  "odd" chunk size in bytes
  23. Decimal number  offset to chunk catalogue CC
  24. Decimal number  offset to "helpful" sprite
  25. Decimal number  size in bytes of the "helpful" sprite info
  26. Decimal number  offset to key frames                    [0/null -> no keys]
  27.                 other gunge as required
  28.  
  29. (all fields are ASCII text terminated by NewLine; spaces
  30. ignored, arbitrary comment text after numeric field permitted)
  31.  
  32. byte CC: start of catalogue of chunks
  33.          this has NC+1 entries of the form:
  34.               file offset of chunk (maybe multiple of 1024)
  35.               size of video data
  36.               size of sound data (immediately after video data)
  37.          arranged FO,BS;OS<newline> (spaces permitted except in numbers)
  38.  
  39. The 'key frame offset' points to a set of NC (not NC+1) blocks of data
  40. containing x*y*z bits. These allow the decompressor to start at a particular
  41. chunk. Starting at the first chunk doesn't need a reference to the key frame
  42. offsets.
  43.  
  44. If the pixel depth is 8, then a palette may be provided by including the text
  45. 'palette <decimal number>' which gives the offset of the palette in the file
  46. (the palette is stored as 256 triple bytes, r then g then b). If there is no
  47. palette, then the data is taken as 0-255 greyscale.
  48.  
  49. If the sound format is 2, the name of the sound decompressor file follows after
  50. a single space: '2 soundxxx'. Playing programs rely on this to find the
  51. decompressor.
  52.  
  53. Example:
  54. ARMovie
  55. The Concert
  56. (c) Notts University 1991
  57. Created by Notts University, digitised by Acorn Computers
  58. 1
  59. 160 pixels
  60. 128 pixels
  61. 16 bits per pixel 
  62. 25 frames per second
  63. 1
  64. 12000 Hz samples
  65. 1 channel
  66. 8 bits per sample (exponential)
  67. 50 frames per chunk
  68. 57 chunks
  69. 204080
  70. 192992
  71. 10580256 catalogue offset
  72. 512 sprite offset
  73. 20480 sprite size
  74. 105602 key frames offset
  75.  
  76. Multiple Sound Tracks
  77. ---------------------
  78.  
  79. The single video track can have an arbitrary number of sound tracks associated
  80. with it. Extra sound track data for each sound parameter follows the sound
  81. track marker "|" plus the sound track number. Different sound tracks can have
  82. completely different parameters - compression format, sample rate, number of
  83. channels, number of bits per sample. The first sound track is played by default
  84. and does not follow a |1 marker - thus the first additional sound track has
  85. parameters following a |2 marker.
  86.  
  87. Example:
  88. ARMovie
  89. The Concert
  90. (c) Notts University 1991
  91. Created by Notts University, digitised by Acorn Computers
  92. 1
  93. 160 pixels
  94. 128 pixels
  95. 16 bits per pixel 
  96. 25 frames per second
  97. 1                               |2   2 CELP1               |3  1
  98. 12000 Hz samples                |2   16000                 |3  20000
  99. 1 channel                       |2   2 channels            |3  2 channels
  100. 8 bits per sample (exponential) |2   16 bits per sample    |3  4 bits (adpcm)
  101. 50 frames per chunk
  102. 57 chunks
  103. 236080
  104. 228992
  105. 10580256 catalogue offset
  106. 512 sprite offset
  107. 20480 sprite size
  108. 105602 key frames offset
  109.  
  110. The catalogue entries are similarly marked:
  111.  
  112.               file offset of chunk (maybe multiple of 1024)
  113.               size of video data
  114.               size of sound data 1 (immediately after video data)
  115.               |2
  116.               size of sound data 2 (immediately after sound data 1)
  117.          arranged FO,BS;OS|2 OS<newline> (spaces permitted except in numbers)
  118.  
  119. Playing sound tracks later than the first one uses more memory (the decompressor
  120. reads the chunk up to and including the sound data it needs).
  121.  
  122. 16 bit sound data is aligned to the next word.
  123.  
  124. Although it is possible to have multiple sound tracks in a file with no video,
  125. it is probably better to have multiple ARMovie files instead.
  126.  
  127. A note about the ARMovie's file name
  128. ------------------------------------
  129.  
  130. The movie replay program adds the ARMovie$Suffix to any path name given to it:
  131. it tries to open this file, then tries again with the original path name. (just
  132. like the window manager with !Sprites, !Sprites22 etc). This allows a degree of
  133. personalisation of replay invisible to all programs.
  134.  
  135. Therefore we recommend the follow standard suffix characters:
  136.  
  137. "2" a movie made at half the frame rate of its base movie
  138.     this movie can be expected to be playable on less powerful machines
  139.     (generalise if required!)
  140.  
  141. "S" a movie made with much smaller chunks than its base movie
  142.     this movie can be expected to be playable on small memory machines (an "S"
  143.     suffix movie may not work from a CD-ROM drive). For example if the base
  144.     movie has 2 second chunks, then an "S" suffix might only have 1 second
  145.     chunks.
  146.  
  147. "L" a movie made with much larger chunks than its base movie
  148.     this movie will not work on CD-ROM, but can be copied from CD-ROM to
  149.     a faster filing system (winchester, magneto-optic) and played. Such movies
  150.     will usually require an ARM3 (or better) to replay them.
  151.  
  152. If two suffixes are available, then the 2 should come first.
  153.  
  154. Calling programs should use the shortest name possible.
  155.  
  156. A note about compression numbers
  157. --------------------------------
  158.  
  159. The compression values allow for new video (de)compressors to be written in the
  160. future. The Player program inspects the video value and, if it cannot process
  161. the format (using the Decompress codes: see "DecompIf"), calls
  162. <ARMovie$Dir>.DeComp<X>.!RunImage where <X> is the decimal string of the value
  163. of the compression type. Thus new compression types can be added transparently.
  164.  
  165. Compression types are allocated as follows:
  166.  
  167.    0-99: Acorn
  168.          video                                     audio
  169.          0: no video                               0: no audio
  170.          1: 'Moving Lines' compression             1: basic audio
  171.          2: 16bpp uncompressed (15 bit data)       2: 'indirect' audio
  172.          3: 10bpp YUV chroma horiz subsampled by 2
  173.          4: 8bpp uncompressed [pixel depth=8]
  174.          5: 8bpp YUV chroma horiz and vert subsampled by 2
  175.          6: 6bpp YUV chroma horiz and vert subsampled by 4
  176.          7: 'Moving Blocks' compression
  177.          [all but type 4 have pixel depth=16]
  178.          8: 24bpp uncompressed
  179.          9: 16bpp YUV chroma horiz subsampled by 2
  180.         10: 12bpp YUV chroma horiz and vert subsampled by 2
  181.         11: 9bpp YUV chroma horiz and vert subsampled by 4
  182.          [all pixel depth=24]
  183.  
  184. 100-199: EIDOS
  185.  
  186. 200-299: Irlam instruments
  187.  
  188. 300-399: Wild Vision
  189.  
  190. 400-499: Aspex Software
  191.  
  192. Different compression types may have different sound compression (indeed, the
  193. entire meaning of the sound compression field is defined by the video
  194. compression type). However, if the sound compression is the same as one of the
  195. other sound compression methods, then the same number should be used - and,
  196. conversely, if a different sound compression method is being used, then a
  197. different number should be used. (Whew, what a nasty sentence). Thus companies
  198. should either use recognised sound compression numbers (and code...) or they
  199. should restrict their sound compression numbers to the same range as their
  200. video compression numbers.
  201.  
  202. Providing new sound compression formats should be done in format 2.
  203.  
  204. Decompress formats
  205. ------------------
  206.  
  207. For any formats which use the Decompress Interface, in particular format 1,
  208. the Acorn Moving Lines compression algorithm, there are some restrictions to
  209. the format:
  210.  
  211. - the chunks should be consecutive: the !ARMovie.Player tries to load pairs of
  212.   chunks in order to address CD-ROM access latency.
  213.  
  214. - the chunks are on CD-ROM sector boundaries, padded by zero.
  215.  
  216. !ARMovie.Player understands audio types 0, 1 and 2. In format 1 there are 10
  217. sound formats:
  218.  
  219. 8 bit linear unsigned mono or stereo
  220. 8 bit linear signed mono or stereo
  221. 8 bit exponential mono or stereo
  222. 16 bit linear signed mono or stereo
  223. 4 bit ADPCM (compressed 16 bit linear) mono or stereo
  224.  
  225. The software decompression of 4bit ADPCM requires output buffers the size of
  226. the supporting machine's sound format - 8 bit ones on current machines. In
  227. format 2 there is an arbitrary number of sound formats.
  228.  
  229. A note about Stereo sound
  230. -------------------------
  231.  
  232. For a stereo sample, the left channel is the first sample, the right the
  233. second, etc. If this is not the case, include the word "reversed" in the
  234. number of channels field: "2 channels reversed".
  235.  
  236. WARNING: for type 1, audio type 1, Stereo 16 bits linear assumes that the
  237. start of each sound chunk is word aligned.
  238.  
  239.